fix(gfql/polars): Contains honors regex=/flags= (B1, viz-filter #1673)#1674
Closed
lmeyerov wants to merge 1 commit into
Closed
fix(gfql/polars): Contains honors regex=/flags= (B1, viz-filter #1673)#1674lmeyerov wants to merge 1 commit into
lmeyerov wants to merge 1 commit into
Conversation
The native polars filter_by_dict lowering of the Contains predicate always
used str.contains(literal=False), so contains(pat, regex=False) was still
regex-interpreted — a literal pattern with a metacharacter over-matched
(contains('a.c', regex=False) matched 'abc'), diverging from pandas/cuDF;
flags= was also dropped. Now regex=False lowers to a literal match
(case-insensitive literal folds both sides to match pandas), and regex mode
maps case=/flags= to a Rust-regex inline flag prefix.
First increment of the viz-filter → GFQL Cypher conformance work (#1673):
the extended Cypher dialect's regex operator must run correctly on polars.
+1 engine-parametrized differential-parity test; ruff + mypy clean;
polars chain + row-pipeline parity suites 150 passed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lmeyerov
force-pushed
the
dev/gfql-polars-contains-regex-fix
branch
from
July 2, 2026 16:19
b8f7d2c to
6c68f1c
Compare
Contributor
Author
|
Folded into #1660 — the Contains regex/flags fix is a fix to #1660's own polars engine code, so it now lives there (cherry-picked as a18c594, same author/content/message, on top of #1660's team-polish commit). #1675's base retargeted to dev/gfql-polars-engine. Part of shrinking the stack (11→9 PRs). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First increment of the viz-filter → GFQL Cypher conformance work (#1673). Targets the in-flight polars-engine branch (#1660) since the fix is in its
filter_by_dictlowering — fold into #1660 or take as a stacked fix, your call.Bug
The native polars
Containslowering (lazy/engine/polars/predicates.py) always usedstr.contains(..., literal=False), so a literal request (contains(pat, regex=False)) was still regex-interpreted: a pattern with a metacharacter over-matched. Proven:contains('a.c', regex=False)matches'abc'on polars but only'a.c'/'a.c.d'on pandas/cuDF.flags=was also silently dropped.Fix
regex=False→ literal match (literal=True); case-insensitive literal folds both sides (matches pandas' result — polars has no literal+case flag).case=/flags=(IGNORECASE/MULTILINE/DOTALL/VERBOSE) to a Rust-regex inline flag prefix(?ims…).Why it matters
The viz filter language emits literal
CONTAINS/LIKEas well as regex; without this, a literal filter with any regex metacharacter over-matches on polars. Prereq (B1) for the Cypher=~regex operator landing cross-engine (#1673).Tests
test_polars_contains_regex_and_case_parity): literal/regex × case-sensitive/insensitive, polars == pandas. Fails before the fix (literal.matched'abc'), passes after.🤖 Generated with Claude Code